旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � KINGDOMS � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � KINGDOMS MANAGER DOCUMENTATION � � Version 2.21 � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � � � Programming & Design : Dave Chapman : The Web BBS � � � � Copyright c 1993, 94, 95, 96, 97 - Dave Chapman � � All Rights Reserved � � � � 3:712/523@FidoNet 169:3005/2@BattleNet � � � 쳐컴컴컴컴컴컴컴� kingdoms@tpgi.com.au 컴컴컴컴컴컴컴컴� � � � - Kingdoms Support Page - � � http://www1.tpgi.com.au/users/kingdoms � � � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 TABLE OF CONTENTS 컴컴컴컴컴컴컴컴� SECTION 1 - INTRODUCTION 1.1. Overview SECTION 2 - FILE MENU 2.1. Edit Paths 2.1.1. BBS (Doorfile) Path. 2.1.2. Kingdoms Game Directory. 2.1.3. ASCII/ANSI paths. 2.1.4. Netmail Path. 2.1.5. Inbound Directory. 2.1.6. Outbound Directory. 2.1.7. Recon Directory. 2.1.8. Temp file path. 2.1.9. Report Viewer 2.1.10. KM Defaults 2.2. Check Paths 2.3. Other 2.3.1. Sysop & BBS Name 2.3.2. Delete Inactive User Days 2.3.3. Days to keep Log data. 2.3.4. Kingdoms Net ID. 2.3.5. Poll Frequency 2.3.6. Self Correction Frequency 2.3.7. Allow Proving Locally? 2.3.8. Allow Raiding Locally? 2.3.9. Next Reset Due 2.4. About Kingdoms 2.5. Maint Flag 2.6. User On Flag 2.7. Logs SECTION 3 - NETWORK 3.1. Your Routing 3.1.1. Setting Yourself Up : In Brief 3.1.2. KIDX.DAT 3.1.3. Default Outbound 3.1.4. Normal Outbound 3.2. Preferences 3.2.1. Mail Type - Hold/Direct 3.2.2. Crashmail - Yes/No 3.2.3. Compression - Zip, Arj, Rar, None. 3.3. Alias 3.4. Verify 3.5. Erase Routing 3.6. Net Times 3.7. Zero Times 3.8. Defaults 3.9. Index File Dump 3.10. Link Diagram 3.11. Worms 3.11.1 What IS a Worm? 3.11.2. Spawning a Worm 3.12. Other Routing 3.13. Reports 3.13.1. Overview 3.13.2. Worm Report Layout 3.13.3. Routing Report Layout SECTION 4 - REGISTRATION SECTION 5 - COORDINATOR APPENDIX A : MAIL ROUTING A.1 Overview A.2. Defining your Routing - Standard Systems A.3. Defining your Routing - Intermediate Hubs Section 1 - Introduction The Kingdoms Manager (or just `The Manager') is the control centre of Kingdoms. It provides the Sysop and Kingdoms coordinator with all facilities needed to manage and maintain the Kingdoms realm operating on his or her BBS and on the network itself. This document is NOT intended to be an installation manual. If you're installing the game, please see KSYSOP.DOC for that sort of information. This document simply takes each option available to you in the Manager and explains what it does and what it's for. If you find yourself stuck, or just want to know more about something in the Manager, then this is a good place to be! 1.1. Overview The Kingdoms Manager (KM) should reside in and be executed from your main Kingdoms directory. This is where KCFG.DAT, the Kingdoms configuration file, resides and where the Manager expects to find it. If the configuration file cannot be found in the current directory when KM starts, the Manager will create a new one using defaults. When you start KM you are presented with the main Manager panel. You can use your arrow keys to select options or use Alt-letter key combinations to jump to an option you want. Menus will pop down for the option you're on and again you can use your arrow keys to choose which option on the menus you're interested in, or press the capitalised letter of each menu option. Having positioned yourself on the one you want, press Enter to select it. The following sections describe each option available and it's function. Section 2 - File Menu 2.1. Edit Paths 2.1.1. BBS (Doorfile) Path. This is the directory where Kingdoms expects to find the DORINFO?.DEF or DOOR.SYS drop file which your BBS creates when shelling to the door. You can override this parameter by using the Kingdoms /D parameter to fully specify the drop file you wish to use. You would do this primarily if you're using the DORINFO#.DEF format drop file, where `#' is the node number in multiline sites. See the Installation section in the Sysop documentation for further detail. This entry is ignored if Kingdoms is entered locally using the /L parameter. In this situation, the required information is taken from the configuration information specified in the Manager. 2.1.2. Kingdoms Game Directory. This is the directory where all your main (.exe) Kingdoms files and game data files (.dat) are located . Generally, this will be something like C:\DOORS\KINGDOMS. You should be in this directory when you start Kingdoms itself or the maintenance/network utilities. 2.1.3. ASCII/ANSI paths. Kingdoms uses .KDI (Kingdoms DIsplay) format files for scoreboards, newsfiles, and other files created by or used by the game to display information to the players. These files always reside in the Kingdoms (game) directory above. If told to, using the /A parameter at runtime, the maintenance utility (KMNT) will also create ANS and ASC flavours of those files. If created, they are placed in the ASCII/ANSI path specified. 2.1.4. Netmail Path. When Kingdoms creates outbound files, it creates a .MSG style Netmail message in your mailer's netmail folder. The message is a file attach message to which files in the Outbound Directory are attached. The status on the attached files is Kill Sent, which means the files will be removed from your system by the mailer when they've been forwarded to the destination node. If you don't plan to participate in a net, you can just make this C:\KINGDOMS (your Kingdoms directory). If you do, this should be the directory in which your mailer stores its Netmail (.MSG) files. 2.1.5. Inbound Directory. This is the directory where Kingdoms should look for incoming files. It will usually be the same directory specified in your mailer inbound (NOT your mailer download!) directory. If you don't plan to participate in a net, you can just make this C:\KINGDOMS (your Kingdoms directory). 2.1.6. Outbound Directory. This directory is the directory where Kingdoms will put files it generates going out to other Kingdom Realms, or BBS's. It does not have to be a directory related to your mailer in any way and will generally be a directory under Kingdoms for these files, eg, C:\KINGDOMS\OUTBOUND\. If you don't plan to participate in a net, you can just make this C:\KINGDOMS (your Kingdoms directory). 2.1.7. Recon Directory. Data on other Realms is held by Kingdoms in Recon (Reconnoiter) files. These files reside in this directory. Again, this will normally be a separate directory under your Kingdoms directory. If you don't plan to participate in a net, you can just make this C:\KINGDOMS (your Kingdoms directory). 2.1.8. Temp file path. When working, Kingdoms sometimes need to make temporary files and this is the place where they'll be put. Generally, this will be the Kingdoms directory itself. Where you put this does not matter particularly to Kingdoms, but it's recommended you make it a local drive in a networked environment to minimise traffic during heavy disk activity. Kingdoms includes the facility for players to chat with each other in a multinode environment. This directory is also used to store the multinode communication files. 2.1.9. Report Viewer This entry is the path *and* filename of your preferred text editor/viewer. When Reports (discussed later) return to your system, the data they provide are stored in various Report files. The editor you define here is executed when you select a report view in the Network options of KM. Valid entries for this field might be : C:\DOS\EDIT.COM (The DOS editor) C:\UTIL\LIST.COM (List) C:\UTIL\Q.EXE (QEdit) You may prefer to use an editor such as QEdit rather than a viewer such as LIST. The worm report is not sorted and holds information from worms in order of arrival. The right editor (e.g. QEdit) will allow you to do any sorting you may desire. To accommodate sorting, incoming Worm data always contains the Worm ID then the full Julian date and timestamp of the Worm. Sorting on the first 13 columns therefore will always give you your incoming Worm data sorted by Worm ID, then date. 2.1.10. KM Defaults As mentioned, if an Configuration file doesn't exist, KM will create it for you. The defaults provided are : - BBS (Dorinfo1.Def) Path : C:\KINGDOMS\ - Kingdom (Game Files) Path : C:\KINGDOMS\ - ASCII Text Files Path : C:\KINGDOMS\TEXTASC\ - ANSI Text Files Path : C:\KINGDOMS\TEXTANS\ - Net Mail Path : C:\FD\NETMAIL\ - Inbound Files Path : C:\KINGDOMS\IN\ - Outbound Files Path : C:\KINGDOMS\OUT\ - Recon Data File Path : C:\KINGDOMS\ - Temp Files Path : C:\KINGDOMS\ - Report Viewer : C:\UTIL\Q.EXE 2.2. Check Paths This option will examine each of the entries you've configured in `Edit Paths' to check they're valid. Any which are not will be highlighted and should be corrected before attempting to run Kingdoms. It's a good idea to select this option whenever you've edited your paths as it will pick up any typos that may have crept in unnoticed to you. 2.3. Other 2.3.1. Sysop & BBS Name Self explanatory. Your name and the BBS name. If you decide to register Kingdoms, the names entered here MUST match the ones you send in on your Registration form. If you enter Kingdoms locally, the Sysop name here is also the default logon name in Kingdoms when using the /L startup parameter. 2.3.2. Delete Inactive User Days Users who have not logged in for the number of days specified here will be removed automatically by Kingdoms maintenance. 30 is a good default. 2.3.3. Days to keep Log data. During maintenance, Kingdoms will automatically trim all it's log files to purge old/unwanted data. The number entered here specifies how many days worth of data to keep when doing the purge. Coordinator's please note : the log created when performing Coordinator functions, such as adding or deleting nodes on the network, is never trimmed automatically as the potential is too high for important historical information to be lost. Any trimming/deletion must be performed by hand on KCOORD.LOG. 2.3.4. Kingdoms Net ID. This field is used to specify which Kingdoms net this game is operating in. If your board is connected to several Kingdoms nets, each Kingdoms game in each network must be set up as a separate game and MUST have a different net identifier. If you're participating in a net, your Coordinator will tell you what Net ID your game is using. Make SURE you get it right as Kingdoms will not process inbound or outbound files if the data within them belongs to a different net Id than the one you have defined. Your Network ID will be alphabetic numeric characters to specify your Id. Special characters will cause problems as this Id is used in the generation of outbound file names from your Realm. The NetId is not case sensitive. An up-to-date list of Network Id's currently in use (so you can select yourself one that hasn't already been used) is maintained on our web site, http://www1.tpgi.com.au/users/kingdoms. 2.3.5. Poll Frequency Poll Frequency is only used if you're participating in a Kingdoms network. Kingdoms will to keep track of how often mail takes to move between (both to and from) any given node and all other nodes in the Kingdoms network. The value entered here specifies how often, in days, Kingdoms should send automatic polls to all other Kingdoms nodes to maintain network statistics. The statistic data can be viewed by you and your users using option `N' on the Kingdom Realms menu. The data provided will look something like : -*Net Statistics*- Mail to Mail From No. Kingdom Realm Average Average 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 1 - The Web N/A N/A 2 - Bad Company 2 days 3 days 3 - Way Out West 3 days 4 days 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Press any key ... Of course, there will be one node listed for each node in your Kingdoms network. The N/A next to the Web above indicates Not Applicable. The Web in this case, is the home realm and, of course, there are no mail statistics to report! In the above example, it takes two days (on average) for mail to get from The Web (the local Realm) to Bad Company. It takes three days for mail on Bad Company to get to The Web. Note that the Poll Frequency value is based on day in the year (ie, the Julian day) not the day polling was first requested. For example, a value of 4 will NOT necessarily poll other nodes the first time it runs and for every four days after that. It polls if the current day or the year is divisible by four. If you want Kingdoms to poll all other nodes every day, just set the Poll Frequency to 1. 2.3.6. Self Correction Frequency Self Correction is a major feature and an integral part of Kingdoms network management. Since version 2.10, Kingdoms carries the default node routing/link information originally specified by your Coordinator within the Index itself. With this information available, each node is able to intelligently work out what connections (outbound or routed) it should have with what other nodes. This effectively frees the Sysop of each node having to know anything about the network itself as is required to get your routing right in most other InterBBS games. A typical example of where this is useful is when a routing change is required. Rather than the coordinator having to tell every node in the network of the change and make sure everyone affected updates their routing, the Coordinator can simply issue a routing update from his or her node. Each realm the update reaches will then automatically (in inbound processing) re-evaluate it's routing rules and reconfigure them if necessary to the specified settings. It may have already occured to you however that updates may go astray or not arrive at their destination for some reason. If they miss getting a node connection update, how can the problem be fixed without further manual intervention? This is where self-correction is used. The value you specify here is how often you want your node to poll your Default Outbound for `self-correction' information. If you specify 5 for example, then every five days your node will automatically request update information from your Default. The information it recieves and processes by this request is effectively a complete copy of your Default's index file. That information will be compared against the local Index and any modifications to the default routing or to Sysop/BBS names will be applied locally. Likewise, downlinks from THAT node will then receive any missed updates by self correction and the information will flow down the network until all changes are effected on all nodes. Note the importance of the Default outbound here. For self correction to work properly, your Default Outbound MUST be the most direct link `upwards' in the network to the Coordinator node. Thus in many parts of the Manager and in the documentation, the Default is also called your `uplink'. This is required so that correction information always flows outward from the Coordinator node which, by definition, must always be correct itself. If the Default is set to a node which is not on a direct path to your Coordinator, self correction may actually pick up old data which, when re-evaluated, may incorrectly configure your routing based on out-of-date Index information on the link specified as the Default. During the automatic evaluation of your index links Kingdoms will, of course, set your Default to the right uplink. You don't normally have to worry about getting this right as Kingdoms will do it for you. This information is only pertinent to those who need to change their Default manually for some (rare) reason. A self-correction frequency of five is suggested as a good default. The coordinator node must never have self correction turned on and it should be left as a zero value. 2.3.7. Allow Proving Locally? If set to `N', players cannot select the

roving Grounds option in the game. They cannot therefore challenge each other to one-on-one combat. This can be turned off if desired to promote interBBS play and stop players from attacking and/or killing each other on the Local realm. 2.3.8. Allow Raiding Locally? If set to `N', players cannot select the aid a Castle option in the game. They cannot therefore enter another players castle locally to attack them and possibly kill them, pillage gold from their vault and/or steal their equipment. This can be turned off if desired to promote interBBS play and stop players from attacking and/or damaging/destroying each other on the Local realm. 2.3.9. Next Reset Due The Coordinator has the ability to force a reset network wide as he/she desires. This line allows you to see if one is due and, if so, when it will take place. If there is no reset pending, the words `None Scheduled' will appear beside the prompt. 2.4. About Kingdoms Gives general information about Kingdoms and the Author. 2.5. Maint Flag When Maintenance starts, a flag within Kingdoms is set on indicating this. If a player attempts to log on while Maintenace is running, Kingdoms will inform them of this and ask them to wait (or exit with a keypress) a short period until it completes before allowing the player to enter the game. If something serious happens such as a crash or power failure while maintenance runs, the flag may not be flipped off as it normally is when Maintenance completes. This will effectively bar players from entering the game at all. Should this happen, simply select this option and confirm you want the flag turned off and all will be well again. If this DOES become necessary, I suggest you also check your KMNT.LOG to see if some sort of error or problem is being reported. 2.6. User On Flag When a player is online, their user record is marked to reflect this. As with Maintenance, a major system problem may mean this flag doesn't get switched off. Selecting this option allows you to turn all `user online' flags off. Of course, you shouldn't run this while someone is actually online! 2.7. Logs Allows you to select any game log for viewing (using the external editor defined in Paths) without leaving the Manager. Section 3 - Network 3.1. Your Routing 3.1.1. Setting Yourself Up : In Brief Network Routing is the area you use to identify your node and the nodes you exchange Kingdoms mail with to Kingdoms. To enter Network Routing, you must have a valid KIDX.DAT file which will be available from your Kingdoms Coordinator. Setting this up is very simple. All you need to do is identify from the list presented which node you are in the Index. Based on the Connection information contained in the Index, the Manager itself will configure the rest of your routing automatically for you. It is not the purpose of this document to tell you how to set this up - the Sysop documentation (KSYSOP.DOC), Installation section can tell you that. Provided here is a general discussion of what things are and what they do so you understand fully what is happening when it is set up, or to give you help if you are experiencing difficulties. 3.1.2. KIDX.DAT The KIDX file is your Kingdoms `nodelist'. It contains an entry for each BBS in your Kingdoms network. Unlike a lot of other InterBBS games, it is not a straight text file you can edit. The reason for this is that Kingdoms manages it, not you, and there is therefore no reason why you should need to edit it manually. Your first KIDX.DAT will be provided by the Coordinator of your Kingdoms network. Any changes from that point on are handled automatically by Kingdoms when the Coordinator distributes them. There should be NO need for you ever to edit this file. Indeed, if you try, you could easily break your routing, so DON'T! 3.1.3. Default Outbound You will have one Default Outbound on your system. Your Default Outbound an outbound just like your Normal Outbound nodes with one important distinction - it is the node to which you connect for Kingdoms mail WHICH IS THE MOST DIRECT PATH BACK TO YOUR COORDINATOR NODE. Normally you don't have to worry about this as Kingdoms will work out which node should be your Default and mark it appropriately and automatically for you. If you are unsure however, you can generate a Link Diagram and identify from that the node your Default should be (it is the node marked `Uplink' in the diagram for your node) and set it accordingly. As described previously, the Default MUST be the most direct path to your Coordinator node for Self Correction to work. If it is not, you should disable Self Correction by setting it to zero. 3.1.4. Normal Outbound A Normal Outbound is simply that. It's a node in your nodelist with which you communicate directly. That is, you call them, or they call you, to transfer Kingdoms data. Like the Default Outbound, you can only route data for other nodes to an Outbound to get it out on the network and to the place it should be going. 3.2. Preferences When selected, a list of all outbound nodes on your system (both Default and Normal) is presented. You can then tailor options for mail for your outbound node(s) to suit your preferences. The possibilities include type of mail, (hold or direct), crashmail (yes or no) and compression type (ZIP, ARJ, RAR or None). While the highlight bar is on the outbound node you're interested in changing preferences for, F1, F2 and F3 will toggle through mail type, crashmail and compressions options respectively. 3.2.1. Mail Type - Hold/Direct Pressing F1 will toggle between Hold and Direct mail for the highlighted node. That is, the .MSG file attach will be marked `hold' (waiting for a call in to pick it up) or direct (will be delivered on either an outgoing or incoming call to/from the destination node). 3.2.2. Crashmail - Yes/No Pressing F2 will toggle crashmail on and off. If on, any new .MSG file attach created will be marked Crash, Immediate. As soon as your mailer has the opportunity to do so, an outbound call will take place to (attempt to) deliver the mail. This generally means an extremely good throughput of mail to/from a system but can cost in terms of phone bills. Not using crashmail generally means you want your Kingdoms data delivered to its destination during normal mail hours/sessions. 3.2.3. Compression - Zip, Arj, Rar, None. Compression is available on all outbound packets in Kingdoms using your choice of the standard compression tools, ZIP, ARJ and RAR. Note that this is specifying compression for OUTBOUND packets only. Kingdoms will scan Kingdoms inbound data, work out what compression format, if any, is being used, and decompress it accordingly if required. In other words - Inbound processing pays no attention whatsoever to what is specified here when decompressing packets - it decompresses inbounds according to the archive type it detects itself. When Knetout runs, it will search for compression on any outbound packets and decompress them accordingly. It will then do normal processing to add outbound data then, according to the type specified here, compress them again ready for transmission. Kingdoms must be able to locate the archiver(s) you have specified either in the current directory, or in a directory on the path, when it needs them. You should, of course, make sure that the destination outbound supports (ie, is able to decompress) any archiver type you choose when compressing mail that is destined for that node. 3.3. Alias Much as it would be nice if everything stayed stable and systems kept working, it is a fact of life that nodes will come and go, addresses may change and other less desirable things may happen. Such events can create havoc with a well running network! To help manage these changes, Aliases are supported under Kingdoms. An Alias basically comprises two addresses - the `Convert From' and `Convert To' addresses. These are simply addresses which allow information destined for one node to be readdressed to another dynamically, or `on the fly'. The following example will explain an example of where this may be necessary. Let's say the a node with address 1:2/3 has dropped their Fidonet link (ie, being a Fido zone) and no longer wants to (or can) use their original address. Let's also assume that the board is a member of BattleNet and has the address 169:2/3 on that network. The node who wants to change should notify their Coordinator who will distribute an Index Change instruction, telling all boards of the change. That's fine, and everyone will start distributing data to the new address as they should, but there may be a considerable amount of data already in transit in the network for the old address. When it reaches a node who has already processed the update, the destination address (the old address) for the inbound transit will no longer exist, and the transit data would be returned to the sender as undeliverable. Not a really good way to do it! This is where aliases come in. Quite simply, when a Change order comes into a node, not only does Kingdoms do the Index change, but it will ALSO, using the example above, create an alias address with a `Convert From' of 1:2/3 and a `Convert To' of 169:2/3. When transit data comes in for the old destination address, but to a node who has the new address in their Index, it (the old address) will still not be found on the Index. Kingdoms will then however, check the Alias file and find the old address in the `Convert From' field of one of the Alias records. What it will do then is replace the destination address on the inbound transit with the `Convert To' address (the correct, or new, one) and continue to process it. The network is not affected, the data gets to where it should and no problems will arise even though not everyone in the network has yet processed updates. Note also that all this happens automatically and there is no need for human intervention, other than for the Coordinator to issue the original Change instruction. You can if you wish set aliases yourself, but there will rarely be a need to do so. It's better to let Kingdoms manage them. A maximum of 10 Alias records are held in Kingdoms at any one time, which should be more than ample. If a new one needs to be added and no space is available, the one which is oldest (referenced the longest time ago) will be overwritten to make way for the new. 3.4. Verify The Verify information in Kingdoms is worth running after you've changed your routing, should you decide to do so. It simply goes through your routing definitions, summarises them, and presents the summary data to you on screen. It's a nice check to see if everything is ok & I suggest you do it periodically. 3.5. Erase Routing If you've done a lot of things to your routing or incorrectly set something, such as your node on the Index file, you can erase all your Routing rules and start over with a fresh slate. This option allows you to do this. Having confirmed this is what you want to do, you will need to reenter the Network Routing options to respecify your node again, or your InterBBS functions will not operate. 3.6. Net Times This is an extended listing of the Net Times list available to players in the Kingdoms InterBBS options. It shows full detail of how long data is taking to get from your node to and/or from all other nodes in the network. The higher the poll frequency set in the `Other' options of the Manager, the more accurate these numbers are likely to be. A on any node in the list (excluding your own, of course) will allow you to send an immediate Recon Request to that node. 3.7. Zero Times Erases the statistics kept for Net Times. This allows you to `start afresh' with your statistics gathering. You would want to do this most probably after things like network problems are resolved to give your players the most realistic view of the nodes you communicate with. 3.8. Defaults As described elsewhere, Kingdoms is capable of fully managing all your network connections for you. You will not normally have any reason to change these defaults Kingdoms sets for you. Should you do so however, the defaults can be easily restored by choosing this option and confirming that this is what you want to do. 3.9. Index File Dump Choosing this option allows you to dump your index, including your current routing definitions, to a standard text file for ease of reference should you wish it. There are times in Kingdoms you may be informed of a problem with node number xx, where xx is the physical record number of a node in your Index file. As all listings in the Manager which show nodes from the Index are sorted alphabetically by BBS name, they cannot be used to identify which node Kingdoms is talking about in these messages. The Index File Dump is listed (and numbered) according to physical record numbers and can also be used to identify these nodes with ease when required. An example of an Index Dump for the Battlenet League (Netid 59) looks like : Kingdoms 2.19 Index File Dump for Net 59. 12-08-1996 (1996343) at 13:31:50. ====== ============== ============================== ================ ===== Record BBS Address Realm Name Your Routing Mail Node Status Realm Sysop Last Recon Network Connect ====== ============== ============================== ================ ===== 1 169:3800/5 RADAR'S wRECk ROOM This Node N/A Co-Ord Radar No Recon 0:0/0 ------ -------------- ------------------------------ ---------------- ----- 2 169:3800/1 MAX Default Outbound Hold Active Peter Connerty No Recon 169:3800/5 ------ -------------- ------------------------------ ---------------- ----- ... more nodes ... ------ -------------- ------------------------------ ---------------- ----- 20 169:3300/6 Enterprise BBS 169:3800/1 N/A Active Andrew Seeger No Recon 169:3300/1 ------ -------------- ------------------------------ ---------------- ----- The fields for each Realm include : * Record Number : The actual record number of the Realm on the Index File. * Address : The address of the Realm - Zone/Net:Node * BBS Name : The BBS Name shown on the Index to players * Your Routing : Where your node actually routes data to for the respective Realm * Mail Type : Hold or Direct. Only applicable for outbound nodes * Node Status : Coord, Active, Inactive, Deleted, Pending. * Sysop : The Sysop Name shown on the Index to players * Last Recon : The date a Recon was last recieved from this Realm, or No Recon. * Connection : Where the node is physically connected to on the network. 3.10. Link Diagram The Index File Dump described previously produces a list of nodes stating who they are currently routing data to. While this will normally reflect the network defaults, a manual change (override) to the routing specified by Kingdoms may mean the dump doesn't reflect what Kingdoms thinks is the network structure (as defined by the Coordinator) due to your manual modification. In contrast, the Link Diagram generates a picture of your complete network. It shows the Coordinator default links and does not take into account (or depict) any changes you may have made. In short, the Link Diagram is a complete picture of who connects to who in the Kingdoms network according to Coordinator specification. It can be particularly useful if you have made some manual modifications to your network and want to change something in particular back to what it should be without resetting everything automatically using the `Defaults' option on this menu. A comparison between the Link Diagram and connections shown in the Index File Dump is a simple means of identifying areas where your node differs from the Defaults specified by the Coordinator. 3.11. Worms 3.11.1 What IS a Worm? One of the major problems I've found with other Inter-BBS games is the routing of game data. Too often things go astray or are not working properly, often due to a BBS that has it's routing defined incorrectly and is sending data off into a black hole somewhere. Unfortunately, though this is always a major issue in Inter-BBS games, facilities are rarely provided to verify the network setup from any node. The concept of the `Worm' is Kingdom's implementation of just such a facility. A Worm is named such because of it's function. When spawned from a node (any node can spawn a worm to any other node), a Worm will `crawl' through the network for anything up to ten days in an attempt to make it to it's destination. If it cannot reach the destination node in ten days, it will give up and return to the originating Realm. At each and every node it visits on it's way through the Kingdoms network it will, in addition to continuing on it's way to the destination, spawn a message back to the originator. When this message arrives back at the original node that spawned the worm, it will be added to the Worm report, `KWORM.RPT' on the local Realm. In this way, a complete report of the network links from one node to another will ultimately be generated, assuming the link is working as it should. In addition to spawning these informational messages on the Worm's progress, node data will also be added to the Worm on it's travels. That is, it will `grow' as it moves from node to node, compiling data about the nodes it travels through as it goes. Again, when a worm returns to it's origin node, the data gathered will be appended to the Worm report. In normal circumstances then, Worm data returned to the originator will consist of one record for each node the Worm passed through in addition to the compiled information gathered as it moves through the network. If a worm gets to a certain point then messages from it cut off suddenly, there is a problem with the network at the point the messages stopped being spawned back. In such cases, you should notify your Coordinator of the problem (remember to include the Worm report!) so remedial action can be taken. At present, Worms aren't very intelligent. Certainly they provide valuable information about the network so that if you suspect something is wrong with a node, you can spawn a worm to it (effectively `ping' it, in network vanacular) and verify the links between the suspect node and your own. I plan however, in future versions, to add functionality to : * Report on Worms that pass through the same node more than once in transit to its destination. * Report on network `loops' by notifying the local Sysops who are in the `loop'. * Verify Index file structures are consistent on nodes the Worm passes through compared to the originating node. Two points to note about Worms : 1. Use them judiciously. Particularly in a large network, Worm's can generate a lot of network traffic by the time they've done a round trip from origin to destination and back again. Use them, by all means, but do everyone a favour and keep the traffic down by only spawning a Worm when you think there might be a network problem. 2. When you first connect to a Kingdoms network, make sure you *are* connected properly. Spawn a Worm to your network coordinator node (the N>etwork V>erify option in KM tells you who your coordinator is) to make sure you have a link to the coordinator. If that link isn't working, you have a problem! 3.11.2. Spawning a Worm Spawning a Worm is a simple matter. Select the `Worm' option on the Network menu. A scrollable list of available nodes will pop up. Select the node you want to spawn a Worm to and confirm the selection. The only restriction here is that you cannot spawn a Worm to your own node, for what I hope are pretty obvious reasons! :-) The specific format of a returned Worm report is shown (and described) in section 4.9 below. 3.12. Other Routing This is another means of checking suspected problems in the network, or even just a facility to satisfy yourself that all is as it should be. In short, this option will return you complete routing information as defined on any `Other' BBS in your Kingdoms network. When selected, a scrollable window of available nodes will pop up and you can select which one you want to send the request to. When it comes back, the data will be added to your Routing Report, for viewing at your convenience. The Routing data returned includes (nicely formatted, of course!) : * The Realm Name * The Realm Address * A complete list of that node's Index and associated Routing rules. * A full list of Aliases active on the selected node * The version of Kingdoms that the node is running The specific format of a returned Routing report is shown (and described) in section 4.9 below. 3.13. Reports 3.13.1. Overview This option allows you to view the Worm and Routing reports while in the Kingdoms Manager. If you prefer to do this straight from DOS (or other OS), it will be useful for you to know that reports are always named *.rpt for ease of finding/reference. KWORM.RPT and KROUTE.RPT are the Worm and Routing reports respectively. You must have the Report Editor path and filename set up correctly in F>ile E>dit Paths to use this option. See `3.1.9. Report Editor' for more information. 3.13.2. Worm Report Layout The Worm Report will tell you many things about the path and operation of your Kingdoms network. It is first worthwhile to note that whenever you propogate a Worm, it is given a four character ID so you can always tell which worm is which as it's quite possible to send out several at once. Thus, the first characters of a Worm report line will always be `Worm [nnnn] :', where nnnn is the Worm ID. Following is a description of all the lines of text and status information you can come across in a Worm report, and what it means to you. For the purposes of illustration, the worm-id is assumed to be 2468. Worm [2468] : *** Spawned yyyyddd-hh:mm:ss to BBS-Name This line is created when you first select a Worm for propogation. The ID is recorded and the date/timestamp of when you issued it. The name of the BBS to which you requested it go is also recorded. Worm [2468] : --- Passthrough Notification on zz:net/node at yyyyddd-hh:mm:ss This line is created by another node as a Worm passes through it on it's way to a destination. Eg, If BBS-1 sends a worm to BBS-3 and to get there the worm has to pass through BBS-2, then a passthrough notification will be issued back to BBS-1, by BBS-2, as the worm is processed and forwarded on. When you get this, you'll find out a lot about your network. If BBS-1 gets a passthrough notification back from BBS-2, then you know the link to BBS-2 is working fine, both ways, that BBS-2 is running inbound and outbound processing correctly, and at what time of day the outbound processing is run on BBS-2. You know also that BBS-2 has forwarded it on, but you CANNOT be sure it got to the next place (BBS-3) until you get a similar message back from BBS-3, or a message such as those that follow telling you the Worm has reached it's destination and it returning. If you DON'T get something back from BBS-3, then either BBS-2 didn't forward it properly, or BBS-3 didn't process it properly. As BBS-2 has returned your pssthrough notification, it's probably ok and the problem probably lies with BBS-3, but you can make sure of that by requesting a routing report from BBS-2, which will give you detail on what it sends where and should answer that question for you. 3.13.3. Routing Report Layout A routing report is not the same as a Worm, but is very informative in it's own right. A routing report will send a request to any node you wish, asking for detail of that node's routing. The complete routing rules for that node will be returned to the requestor (normally the Net Coordinator) for examination as desired. This is ONLY the information held for routing rules which, if specified incorectly, will cause mail problems in the network itself. Thus, anyone can check anyone else's routing. Indeed, you are encouraged to do so to minimise processing errors on the network, and thus problems and hassles in the game itself. Information considered private to a node (such as registration numbers and status, passwords, user names, etc) is NOT distributed and cannot be requested. Like the worm, a line is written to the routing report when it is first requested to keep track of the date such requests were made. It will read something like `Routing Request generated yyyyddd/hh:mm:ss to BBS-Name.'. Assuming the request gets there and makes it back, the information returned is pretty much the same as you can view of your own realm within the Kingdoms Manager Network options on Routing and Aliases. A sample returned routing report follows : -------------------------------------------------------------------------- Routing Report Created yyyyddd (dd-mm-yyyy at hh:mm:ss) -------------------------------------------------------------------------- Routing at BBS-Name - processed yyyyddd (dd-mm-yyyy at hh:mm:ss) BBS-Name is running Kingdoms vn.nn. addr1 BBS1 (Sysop1) Default Outbound addr2 BBS2 (Sysop 2) Route to addr1 addr3 BBS3 (Sysop 3) This Node addr4 BBS4 (Sysop 4) Route to addr1 -------------------------------------------------------------------------- --- Alias Data --- Alias 1 : Not used. Alias 2 : Not used. Alias 3 : Convert addr5 to addr4 Alias 4 : .... Alias 10 : Not used. -------------------------------- End Routing Info ------------------------ Given that you've set up your own, this should be pretty clear to you by now. Quite simply, all the information that affects routing on the node is returned to the requestor for examination. It is not, of course, possible for someone to change another BBS's routing rules, but by mail you can inform another Sysop of routing rule problems, should any exist and get them fixed so the network continues to operate smoothly. Section 4 - Registration Should you decide to register Kingdoms, this is where you enter the registration number provided. You will be asked for your name plus the BBS name to match up with a registration code provided to you by the Author. Remember that all fields are case sensitive when entering this information! If you've already registered, this option will display your registration details. Registration information is available in the accompanying document, KREG.DOC (or the text version, KREG.TXT). If you're on the Net, you can register with a credit card online at http://www1.tpgi.com.au/users/kingdoms. You can also pick up the latest version of Kingdoms there! Section 5 - Coordinator These options are available only to your Netowrk Coordinator and are fully described in KCOORD.DOC, the League Coordinator's (LC's) documentation, which accompies the Kingdoms distribution archive. Appendix A : Mail Routing A.1 Overview If you're participating in a Kingdoms network, your routing rules are set up and maintained using the Manager, KM.EXE. In short, your rules tell Kingdoms where to send mail for what node in your net. This appendix goes into detail about routing, what it means, and how it works in Kingdoms. Generally you won't need to read it to run your game (Kingdoms will maintain it fully for you) but the information is provided here for those who would like to know more about what's happening `behind the scenes'. When KNETOUT runs, it will examine the routing rules which are stored in the Index file, KIDX.DAT. For nodes which have outbound data, KNETOUT will generate a file attach .MSG in your Mailer directory (as defined in KCFG). The file attached to the message will be placed in your Kingdoms Outbound directory, again as specified in the Manager. Kingdoms does NOT create zillions of outbound files for the same node. It is smart enough to realise if an outbound exists for a node which is being sent more data and will simply append the new data to the existing file. This makes for a much faster and cleaner mail session during transfer. It is VERY important you get your routing rules right or your players will find that attacks don't get through, money is lost they're sending to other Realms, or numerous other undesirable outcomes are possible. Kingdoms will define them for you based on the information available in the Index file so this isn't normally a problem but be aware of the need for caution if for some reason you have need to override the defaults chosen by Kingdoms itself! A.2. Defining your Routing - Standard Systems First up, make sure you have the latest KIDX.DAT file from your Kingdoms co-ordinator. Place it in C:\KINGDOMS and run the Manager. Selecting Network>Your Routing will put you in a screen where your routing rules are defined. This aspect of InterBBS games always seems to cause the most pain, which is why I chose not to use the normal text file interface as I've seen (and seen go wrong in numerous ways!) in other BBS games, but rather built this area to allow you to easily manage your routing rules. You will have a screen before you which lists all the nodes in your `nodelist', your Kingdom Index (KIDX.DAT) file. If this is the first time you've used this option, you'll be asked to define which node YOU are in the nodelist. Using the arrow keys, place the highlight bar over your node and press enter. If your node is NOT listed, then press Esc to get out of there and get an updated KIDX.DAT file from your Coordinator that has you listed. Do NOT set yourself up as another node as mail routing for the game will get very confused to find multiple nodes with the same address on the network! Having selected your node, Kingdoms will configure your routing for you and there'll not normally be anything further you need to do other than perhaps set your outbound(s) to CRASH mail rather than normal mail should you wish it and turn on any compression you want. When this is done, re-enter `Your Routing' and have a look at what Kingdoms has done for you. Please note that the remaining discussion assumes Kindoms has created your routing and for some reason you wish to change it. A full description is provided so you can be sure you know what you're doing but do NOT assume you ever need to do any of this! In normal situations, Kingdoms will handle the whole thing for you and you should NEVER modify your routing definitions without first consulting your coordinator. Not only do you risk disrupting mail for your node if you get it wrong, but nodes who pick up from you and poll your node for network self correction will also feel the effects of a mistake and will have their routing broken in turn! In short, Kingdoms handles it all seamlessley ... if it ain't broke, don't try to fix it! The information you see when you enter Your Routing might look like : Address Name/Sysop Node Routing 3:712/523 The Web (Dave Chapman) This Node 3:712/807 Bad Company (Shane Hunter) Default Outbound (Direct) 69:1171/3 Way Out West (Darren Gibbs) Route 3:712/807 98:765/4321 Another BBS (Sysop Name) Route 3:712/807 This simple example, I hope, is apparent. We have : * The Web is the node on which Kingdoms is being set up. * Bad Company is the BBS to which The Web sends its Kingdoms data. * Way out West's and Another BBS's Kingdoms' data is being routed to Bad Company. * Bad Company will have its routing set up to move data for these two on to wherever they are. Lastly, note that there is a (Direct) listed after Bad Company. This means that mail generated for it will be sent whenever The Web is connected to Bad Company - it matters not who made the originating call. If Bad Company was ringing the Web, then the mail for Bad Company can be placed on Hold to await an incoming call to the Web. Placing the highlight bar on the node you want to change and press F2 to toggle between Direct and Hold status for outbound mail depending on whether you call the node, or the node calls you, respectively. Generally, you can leave everything as Direct, so mail will transfer at all times, unless you have a specific reason for wanting to Hold mail for pickup only. For outbound nodes as well, you can set the `CRASH' flag on and off by pressing F3 while the node is highlighted. If it is on (Y), then file-attach messages created for your mailer will have the CRASH and IMMEDIATE flags set on accordingly. Having set this up, you often won't need to do any more. Kingdoms supports automated update of all Realm Index files so your Coordinator will distribute new nodes and they'll be added to your index file as they arrive without you having to lift a finger. Any new nodes that arrive for addition to your index file will automatically be routed to your Default Outbound so you don't need to worry about the routing of new nodes either. Kingdoms does it all for you! Should you ever want to change your Default Outbound, then just go back into the routing definitions and press Enter on the node you want to make your Default from that point on. You will be asked what you want to do with this node so select the option that defines it the Default Outbound. Kingdoms will prompt you to see if you want to change all other nodes to direct mail through this node and if you do, just hit Yes. Everything will be directed through a new node with just those few keystrokes, nothing more to it. Again, note that the Default Outbound MUST be your direct uplink on a path to the Coordinator node. You can see which node Kingdoms thinks that should be (and it's probably right!) by looking at the `uplink' node for your node on the Link Diagram. If you change it to some other node YOU MUST DISABLE SELF CORRECTION by setting it to zero or you risk the self correction process picking up old network data and incorrectly assigning routing definitions for your node. A.3. Defining your Routing - Intermediate Hubs The above discussion should cover the requirements of most Kingdoms nodes and is very easy to implement. In the example however, The Web is calling only one node and sending all data to that node. If you are an intermediate hub (a BBS where more than one other BBS is picking up or delivering Kingdoms data) things are a little different, though Kingdoms still keeps it quite easy to do with a minimum of fuss. Again, Kingdoms (since version 2.10) does all this automatically and you shouln't need to change it. The following description is here only for those who have some need, and their Coordinator's approval, to do so! After routing configuration has completed, a hub might see a Routing screen such as : Address Name/Sysop Node Routing 3:712/523 The Web (Dave Chapman) Route 3:712/807 3:712/807 Bad Company (Shane Hunter) Default Outbound 69:1171/3 Way Out West (Darren Gibbs) Route 3:712/807 3:712/611 Sci-Fi BBS (Greg Hope) This Node 98:765/4321 Another BBS (Sysop Name) Route 3:712/807 Let's assume now that `Another BBS' is calling us (Sci-Fi BBS) for Kingdoms, not picking it up from Bad Company as is most likely the case above. Simply put the highlight bar on `Another BBS', and press Enter. You'll be given the following options : 1. Make this node the Default Outbound 2. Make this node a normal Outbound 3. Route mail for this node to another node 4. Forget it, no changes Simply select `2' and press enter and the routine list screen will be returned to you. Address Name/Sysop Node Routing 3:712/523 The Web (Dave Chapman) Route 3:712/807 3:712/807 Bad Company (Shane Hunter) Default Outbound 69:1171/3 Way Out West (Darren Gibbs) Route 3:712/807 3:712/611 Sci-Fi BBS (Greg Hope) This Node 98:765/4321 Another BBS (Sysop Name) Normal Outbound (Hold) Simple, huh? Now mail for Another BBS will be held on Sci-Fi BBS until Another BBS calls in for it. As with the Default Outbound, you can press F2 while the node is highlighted to change their mail status from Hold to Direct. Something a little more complex. Assume `Way Out West' calls `Another BBS' for Kingdoms, rather than Bad Company. You want mail for Way Out West to go then to Another BBS rather than being routed to Bad Company. Again, highlight the node you want to change, Way Out West in this case, and press Enter. Choose `3' this time and a list of available nodes will pop up in another window. Kingdoms will ask you to select the node you wish to route data for Way Out West to, so highlight Another BBS and press Enter. The following screen will be returned : Address Name/Sysop Node Routing 3:712/523 The Web (Dave Chapman) Route 3:712/807 3:712/807 Bad Company (Shane Hunter) Default Outbound 69:1171/3 Way Out West (Darren Gibbs) Route 98:765/4321 3:712/611 Sci-Fi BBS (Greg Hope) This Node 98:765/4321 Another BBS (Sysop Name) Normal Outbound A couple of restrictions exist, which are there to protect you from yourself . 1. You cannot route data to your own node. 2. You cannot route data to a node that is not an outbound node. 3. You cannot change the status of the Default Outbound node except for the mail Hold/Direct flag. You must make another node the default outbound before you can modify it. That about covers mail routing. It should be pretty clear I hope! If you have any questions or problems, please don't hesitate to contact me netmail, on the Internet or via the Kingdoms Sysop echo on BattleNet. - End of Manager Documentation -